By cloud computing reference is made to a type of computing which abstracts from physical compute, network, and storage resources and provides shared access to virtual compute, network and storage resources. The components thereof are in a network solution connected by means of a network.
Virtualization provides abstracted access to compute resources (CPU, main memory), networking, and storage. In the following, with virtual machine (VM) reference is made to virtual compute or storage or network resources. Creating a virtual machine refers to deploying or allocating the compute resource, to which storage and networking resources can be added (or associated or connected). Usually a VM is attached to at least one host providing the compute or storage resources.
One common deployment offers a solution in which each host with storage capacity (or storage backend) provides that storage to any virtual machine in the cloud architecture. However, each host is independent of the rest. Inside cloud architecture, the concept of clustering of resources is widely used in order to increase the resiliency of services, improve the efficiency in usage of resources and protect applications running on it from hardware failure.
To orchestrate and manage the cloud architecture, OpenStack can be used. OpenStack is a cloud operating system or architecture that controls large pools of compute, storage, and networking resources. It comprises multiple components which manage specific system components or system areas. In particular, the component Cinder of OpenStack is responsible for managing the storage resources. The Cinder component comprises several subcomponents including Cinder-API, Cinder-scheduler, Cinder-volume.
Cinder-Api is in general responsible for receiving and handling requests and placing them in a message queue. Cinder-scheduler determines and assigns storage volume to which provisioning requests will be sent. Cinder-volume runs on the storage node or host and manages the storage space. Cinder-volume service can run on multiple nodes, each constituting part of the storage pool. Further the storage backend of the hosts may be clustered to build a logical storage volume and the Cinder-volume controls the logical storage. The Cinder-scheduler service is responsible for distributing requests across all nodes that are running the volume service.
Summarizing, Cinder component virtualizes pools of storage devices or storage backend and provides end users with a self-service in form of Cinder API in order to request and consume those resources without requiring any knowledge of where their storage is actually deployed or on what type of device.
FIG. 1 shows an example of a cloud infrastructure based on the Cinder architecture. The cloud infrastructure or architecture according to FIG. 1 comprises Cinder-API 101, Cinder-scheduler 102, and two exemplary Cinder-volumes 103, 104. Cinder-API, 101, is adapted to receive requests, Request, from tenants to manage (create, delete, resize, backup, . . . ) storage volumes and to forward them to the Cinder-scheduler, 102. The Cinder-scheduler 102 distributes this request to one of the available storage backends, 105, 106 and decides which of the storage backends 105, 106 serves the request. Each of the storage backends 105, 106 is controlled by an attached Cinder-volume 103, 104. Cinder-API 101 and Cinder-scheduler 102 may be deployed in a controller node like a storage resource manager. Cinder-volume 103, 104, responsible for the management of the actual storage backends, are deployed on the host, 110, 111 hosting the storage backend, 105, 106. For the sake of simplification it is assumed, there are as many Cinder-volumes as storage backends placed in the cloud infrastructure. Storage volume is offered to virtual machine VM, 107 from storage backends, i.e., typically, storage backends provide storage volumes to tenant VMs.
A storage resource manager like a Cinder-scheduler controls the individual Cinder-volume and the attached storage backend and assigns each of the storage backend individually depending on which of the storage backend can fulfill the request. Thus, a storage resource manager is a service provided in cloud architecture. When a virtual machine is initially deployed, the storage resource manager of the cloud environment is responsible to find the best matching storage volume for that virtual machine. Often there will be several storage volumes to choose from and the storage resource manager has the task to decide which storage is to be provided. The decision may be influenced by load balancing strategies, capacity needed by the virtual machine, storage profile of the storage volume.
The storage backend of the hosts may be clustered to build a logical storage volume and the Cinder-volume controls the logical storage. That means that in advance a virtual machine may be deployed and a storage backend may be assigned to that virtual machine. For example a virtual machine aggregating storage backend of a number of hosts (like for example of 5 hosts wherein each of the host have 1 TB, so that that VM may offer 5 TB) may be provided. This virtual machine has also a Cinder volume so that for the Cinder scheduler it is seen as a host with a certain storage volume (in this example of 5 TB). Consequently a Cinder-scheduler administrates the storage backends of the hosts and has access to the Cinder-volumes without knowing whether it is a physical host or logical storage since the virtual machine is deployed statically and in advance.
However this behavior of Cinder-volume is static. Cinder-volume is adapted to distribute existing storage capabilities of the “own” storage backends to clients. However, it is not possible in the present system to process requests if the storage volume of none of the individual storage backends can fulfill the request, thus if the service request requiring storage volume exceeds the storage volume of the individual hosts, including a storage volume of eventually deployed virtual machines. The consequence is that the request for performing a storage request will fail.